Довольно давно мы писали о технологии Remote Direct Memory Access (RDMA) которая позволяет не использовать CPU сервера для удаленного доступа приложения к памяти другого хоста. RDMA позволяет приложению обратиться (в режиме чтение-запись) к данным памяти другого приложения на таргете, минуя CPU и операционную систему за счет использования аппаратных возможностей, которые предоставляют сетевые карты с поддержкой этой технологии - называются они Host Channel Adaptor (HCA).

Также некоторое время назад мы писали о VMware Paravirtual RDMA (PVRDMA) - технологии, поддержка которой появилась еще в VMware vSphere 6.5. С помощью нее для сетевых адаптеров PCIe с поддержкой RDMA можно обмениваться данными памяти для виртуальных машин напрямую через RDMA API, что важно для нагрузок High Performance Computing (HPC) на платформе vSphere.

Работает PVRDMA только в окружениях, где есть хосты ESXi с сетевыми картами с соответствующей поддержкой, а также где виртуальные машины подключены к распределенному коммутатору vSphere Distributed Switch (VDS). Альтернативой этому режиму использования сетевых карт является технология VMDirectPath I/O (passthrough), которая напрямую пробрасывает устройство в виртуальную машину. Это, конечно, самый оптимальный путь с точки зрения производительности, однако он не позволяет использовать многие полезные технологии VMware, такие как HA, DRS и vMotion.

Недавно компания VMware выпустила интересный документ "Paravirtual RDMA for High Performance Computing", где рассматриваются аспекты развертывания и производительности PVRDMA, а также производится тестирование этой технологии в сравнении с VMDirectPath I/O и TCP/IP:

Читать весь документ, наверное, не стоит - можно довериться методике тестирования VMware и ее подходу к оценке производительности. Тестовый стенд выглядел так:

Состав оборудования и особенности тестирования:

• 8 хостов ESXi 7.0 на платформе PowerEdge C6420 с Intel Xeon Gold 6148 CPU на борту (20 ядер / 40 потоков), 200GB RAM NVIDIA Mellanox ConnectX-5 Ex 100GbE NIC на канале RDMA
• Карты NVIDIA Mellanox ConnectX-5 Ex NIC, соединенные через коммутатор 100GbE NVIDIA Mellanox
• CentOS 7.6, 20 vCPUs, 100GB RAM, ВМ на датасторе vSAN, одна ВМ на хост ESXi
• OpenMPI версии 4.1.0, использующая using openib BTL для транспорта RDMA
• OpenFOAM версии 8, исполняющая тест cavityFine из руководства OpenFOAM. Этот тест исполняет симуляцию течения жидкости с заданными параметрами.

Тут можно просто взглянуть на следующие картинки, чтобы понять, что при использовании PVRDMA вы теряете не так уж и много в сравнении с VMDirectPath I/O.

Результаты теста по времени исполнения в секундах (для 2,4 и 8 хостов, соответственно):

Визуализация результатов при изменении числа узлов:

В среднем, потери производительности на PVRDMA составляют до 20%, зато вы получаете множество преимуществ, которые дает полная виртуализация без жесткой привязки к оборудованию - консолидация, HA и vMotion:

В сравнении с TCP дела тоже обстоят хорошо, результат лучше на 30-80%, в зависимости от числа узлов:

Скачать документ VMware Paravirtual RDMA for High Performance Computing можно по этой ссылке.

Продолжаем вам рассказывать о решении NAKIVO Backup & Replication, предназначенном для резервного копирования и репликации виртуальных машин в инфраструктуре VMware vSphere и Microsoft Hyper-V. В прошлой статье мы рассказывали о выходе новой версии продукта, где появились функции мониторинга виртуальных сред, а сегодня поговорим о лучших практиках его использования.

Компания VMware анонсировала новую версию продукта VMware HCX 4.3, предназначенного для миграции с различных онпремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на платформе VMware vCloud. Напомним, что о возможностях версии 4.2 этого продукта мы писали вот тут.

Давайте посмотрим на новые возможности HCX 4.3:

1. Переход на PostgreSQL

Теперь HCX использует БД PostgreSQL вместо устаревших баз данных, использовавшихся ранее. Для пользователя переход произойдет незаметно, а сами данные в фоновом режиме будут перенесены на новую платформу.

2. Улучшения HCX Network Extension

Теперь для виртуальных модулей Network Extension появились функции высокой доступности (high availability). Так как сервис Network Extension является критичной частью HCX, нарушения в работе которого могут привести к серьезным проблемам с функционированием, то теперь на уровне виртуальных модулей (Virtual Appliance) есть функции HA, которые работают в режиме active/standby. В случае сбоя переключение на запасной узел происходит автоматически.

Диаграмма ниже показывает, как работают виртуальные модули NE, которые формируют пары на каждой из площадок, а во время нормальных операций трафик использует active-туннель между модулями. Другой туннель между standby-модулями также поддерживается, но трафик по нему не идет. На него происходит переключение в случае сбоя основного канала.

HA group 1 и HA group 2 имеют независимые механизмы хартбитов, чтобы мониторить состояние виртуальных модулей.

3. Улучшения OS Assisted-миграций

OS Assisted Migration (OSAM) - это режим миграции виртуальных машин из не-vSphere окружений, таких как KVM и Hyper-V, на платформу vSphere. Здесь было сделано несколько важных улучшений:

• Поддержка новых гостевых ОС - теперь HCX поддерживает миграцию ВМ на базе RHEL 8.x (64-bit) и CentOS 8.x (64-bit) в окружениях KVM на vSphere. Кроме того, можно мигрировать RHEL 8.x (BIOS/GEN-1 & UEFI/GEN-2) и CentOS 8.x (BIOS/GEN-1 & UEFI/GEN-2) из виртуальных машин Hyper-V.
• Совместимость HCX OSAM для vSphere и Cloud Director - теперь при миграции поддерживается связка продуктов VMware vSphere 7.0 U3 и VMware Cloud Director 7.0 U3. 

4. Улучшения юзабилити

• Устранен лимит на 15 символов для имен хостов ВМ на базе MS Windows при кастомизации гостевой ОС.
• Возможность изменять Compute Profile в режиме OSAM. Ранее надо было явно указывать целевой датастор в профиле, теперь же HCX обнаруживает набор датасторов, которые доступны для репликации в кластер. Также происходит валидация, что Sentinel Data Receiver (SDR) имеет доступ к датастору, указанному пользователем.

Более подробно о продукте VMware HCX 4.3 можно почитать на этой странице.

Компания VMware на сайте проекта Labs сделала доступной новую версию платформы виртуализации ESXi ARM Edition 1.8. Напомним, что это специальная версия гипервизора VMware, предназначенная для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства). Также этот гипервизор в будущем найдет свое применение в таких платформах, как Project Monterey. О прошлой версии ESXi для ARM мы писали вот тут.

Давайте посмотрим, что нового появилось в ESXi ARM Edition 1.8:

• Исправление для ACPI, что позволяет поддерживать гостевые ОС OpenBSD.
• Улучшенная обработка ITS device ID width в реализации без поддержки indirect table.
• Улучшенная обработка VMkernel TLB (Translation Lookaside Buffer - он представляет собой кэш для MMU).
• Улучшенная обработка механизма NUMA, особенно в части сообщений об ошибках.

Скачать VMware ESXi ARM Edition 1.8 можно по этой ссылке. Напомним, что апгрейд с прошлых версий этого гипервизора не поддерживается, каждую новую версию нужно устанавливать заново.

Как знают многие администраторы VMware vSphere, у компании есть очень полезный документ "Security Configuration Guide", который представляет собой основное руководство по обеспечению безопасности виртуальной среды. Последняя версия этого документа содержит 87 настроек (мы писали об этом тут), так или иначе влияющих на безопасность как самой платформы виртуализации, так и виртуальных машин и их гостевых операционных систем.

Документ передает концепцию "Secure by design", что означает, что среда VMware vSphere изначально настроена оптимальным образом с точки зрения безопасности, поэтому вносить изменения вам нужно только в случае наличия каких-либо специальных требований именно в вашей инфраструктуре.

Надо понимать, что конфигурация виртуальной среды в целях обеспечения повышенной (относительно дефолтной) безопасности - это всегда компромисс между защищенностью и удобством использования (как и для любой другой ИТ-системы). Из коробки сама платформа, сервер vCenter и виртуальные машины настроены таким образом, чтобы обеспечить максимальное удобство использования при должном уровне безопасности.

Помните, что изменение настроек безопасности - очень опасная штука, которая требует обязательного документирования и оповещения администраторов об этом. Ведь из-за этого они могут получить проблемы с работой отдельных компонентов, но так и не понять их источника, что будет похуже чисто гипотетической маловероятной атаки, связанной с измененной настройкой.

Сегодня мы посмотрим на 15 действительно полезных рекомендаций и настроек, применение которых не сильно снизит удобство использования, но при этом даст чуть более высокий уровень безопасности, что может оказаться вам в каком-то случае полезным.

Структура списка конфигураций и рекомендаций

Давайте сначала взглянем на колонки Excel-таблицы, которая, по-сути, и является списком настроек и рекомендаций, которые вы можете применить в своей виртуальной инфраструктуре:

• Guideline ID - идентификационное имя рекомендации.
• Description - лаконичная формулировка сути этой рекомендации.
• Discussion - описание влияния настройки на конфигурацию среды и операции, а также обсуждение моментов, которые касаются удобства использования инструментов управления в связи с изменением настройки.
• Configuration Parameter - это название расширенной настройки соответствующего компонента, которую вы можете изменить. Понятно дело, что эта колонка заполнена не всегда, так как есть рекомендации, которые регулируются не конкретными настройками, а, например, топологией или подходом к организации среды.
• Desired value - рекомендуемое значение, часто оно является значением по умолчанию, если это не site specific.
• Default value - то значение, которое установлено по умолчанию.
• Is Desired Value the Default? - просто для понимания (и для референса в будущем), установлено ли желаемое значение по умолчанию.
• Action Needed - это тип действия, который необходимо предпринять - изменить настройку, проверить конфигурацию или топологию, добавить или удалить что-то и т.п.
• Setting Location in vSphere Client - очень полезная колонка, позволяющая вам найти нужную настройку в клиенте vSphere.
• Negative Functional Impact in Change From Default? - это как раз информация о влиянии на функционал в случае изменения настройки.
• PowerCLI Command Assessment - команда PowerCLI, с помощью которой можно узнать текущее значение настройки.
• PowerCLI Command Remediation Example - команда PowerCLI по применению настройки.
• Hardening - указывает на то, что это действительно настройка, которой нужно уделить внимание при конфигурации.
• Site Specific Setting - говорит о том, что задать конфигурацию должен сам пользователь, в зависимости от его окружения.
• Audit Setting - указывает, что вам необходимо время от времени проверять эту настройку, чтобы убедиться, что значение по умолчанию не было изменено необоснованно.

Само руководство разбито на 4 категории, которые понятны всем администраторам:

• Хосты ESXi
• Сервер vCenter
• Виртуальные машины
• Гостевые ОС виртуальных машин

Также в документе есть и вкладка "Deprecated" - там находятся те настройки, которые больше не актуальны. Что важно - там помечено, почему это случилось (в колонке Discussion).

Итак, давайте посмотрим на 15 самых интересных и, главное, полезных настроек, которые вы можете изменить, а также рекомендаций, которые вы можете выполнять, чтобы повысить безопасность виртуальной среды в своей инфраструктуре.

Хосты ESXi

• Configure remote logging - это действительно правильная рекомендация. Хосты ESXi должны отправлять свои логи на удаленный сервер Syslog. Самый удобный вариант - это использовать в качестве Syslog-сервера решение VMware vRealize Log Insight. Ведь если злоумышленник проникнет на сервер ESXi, то после своей активности он эти логи удалит, и расследовать будет нечего. С централизованного внешнего сервера удалить эти данные сложнее. На работу виртуальной среды эта конфигурация не влияет.
• Ensure ESXi management interfaces are isolated on their own network segment - это очевидная, но не всегда выполняемая администраторами конфигурация. Конечно же, вся управляющая инфраструктура виртуальной среды должна находиться в выделенном сегменте сети в своих VLAN, куда имеют доступ только администраторы. То же самое касается и сети vMotion, и сети vSAN.
• esxi-7.shell-interactive-timeout и esxi-7.shell-timeout (Set a timeout to automatically terminate idle ESXi Shell and SSH sessions) - по умолчанию сессии командной оболочки и SSH-сессии висят постоянно, что, конечно же, представляет потенциальную угрозу. Лучше ограничить таймаут 600 секундами, чтобы никто эти сессии не смог подхватить.
• Only run binaries delivered via VIB - эта настройка позволяет устанавливать бинарные компоненты только через VIB-пакеты, которые соответствуют установленному Acceptance Level. Если вы не пользуетесь посторонними библиотеками кустарного производства, то лучше эту настройку включить. Когда вам понадобится установить такой бинарник - просто включите эту настройку снова. Но это изменение лучше задокументировать.
• Enable bidirectional/mutual CHAP authentication for iSCSI traffic - настраивать CHAP-аутентификацию нужно обязательно, чтобы предотвратить атаки, связанные с перехватом трафика к хранилищам. Настраивать это недолго, но зато будет больше уверенности в сохранности данных.

Сервер vCenter

• Ensure vCenter Server management interfaces are isolated on their own network segment or as part of an isolated ESXi management network - это та же самая рекомендация по изоляции управляющей сети от сети виртуальных машин, что и для серверов ESXi. Убедитесь, что они надежно разделены с помощью VLAN и других техник.
• Ensure that port mirroring is being used legitimately - эта настройка отключена по умолчанию, но зеркалирование трафика на портах vSphere Distributed Switch надо периодически проверять (vSphere Client -> Networking -> Distributed Switch -> Configure -> Settings -> Port Mirroring). Такой способ атаки - один из самых простых в реализации, если у злоумышленника есть доступ к настройкам VDS (обычно в них никто не заглядывает после первичной настройки). То же самое касается и отправки трафика NetFlow, управление которым производится в разделе vSphere Client -> Networking -> Distributed Switch -> Configure -> Settings -> NetFlow.
• Limit access to vCenter Server by restricting DCLI / SSH - это разумная рекомендация, чтобы злоумышленник не смог залогиниться в консоль виртуального модуля напрямую или по SSH. Уменьшив поверхность атаки, вы сделаете среду более защищенной. Только не забудьте задокументировать это изменение.
• Configure File-Based Backup and Recovery - не ленитесь настраивать и обслуживать бэкап конфигурации вашего управляющего сервера. Однажды это может вам пригодиться как в контексте безопасности, так и в контексте быстрого восстановления системы управления в виртуальной инфраструктуре в случае сбоя.
• Configure remote logging - здесь те же рекомендации, что и для ESXi. Не ленитесь настраивать сервер удаленного сбора логов.

Виртуальные машины

• Limit the number of console connections - очень часто к консоли виртуальной машины не нужно больше одного подключения ее администратора. В этом случае дефолтное количество 40 одновременных подключений лучше уменьшить до 1. Делается это в разделе VM -> Edit Settings -> VM Options -> VMware Remote Console Options.
• Encrypt VMs during vMotion - это полезная настройка. По умолчанию, трафик vMotion шифруется, только если есть такая возможность (Opportunistic). Если у вас хватает вычислительных ресурсов и быстрая сеть, то можно установить это значение в "Required". Это обеспечит защиту от перехвата трафика vMotion, в котором есть данные гостевой ОС виртуальной машины.
• Lock the VM guest session when the remote console is disconnected - лучше включить эту настройку и лочить сессию при отключении удаленной консоли, чтобы брошенная администратором сессия в гостевой ОС виртуальной машины не была подхвачена злоумышленником. На удобство работы это не сильно влияет. Изменить эту настройку можно в VM -> Edit Settings -> VM Options -> VMware Remote Console Options.

Гостевая ОС

• Ensure that VMware Tools are updated - это просто еще одно напоминание, что нужно постоянно следить за тем, что пакет VMware Tools обновлен до последней версии (и желательно поддерживать единый уровень версий для всех машин). В нем содержится много компонентов (кстати, не устанавливайте ненужные), поэтому уязвимость в одном из них может скомпрометировать множество виртуальных машин. То же самое относится и к версии Virtual Hardware - следите за этим.
• Disable Appinfo information gathering - об интерфейсе Appinfo мы писали вот тут (он же Application Discovery). Он позволяет, например, собирать информацию о запущенных приложениях внутри гостевой системы и их параметрах. Механизм Appinfo используется различными решениями, такими как vRealize Operations Manager, для мониторинга на уровне гостевой ОС. Если же вы не используете эти решения в своей виртуальной среде, то данный механизм лучше просто отключить через VMware Tools. Учитывая какое количество багов, касающихся безопасности, в последнее время находится в различных компонентах инфраструктурного ПО, лучше отключить функции Appinfo, которые включены по умолчанию для всех гостевых ОС после установки VMware Tools.

Конечно же, в документе vSphere 7 Security Configuration Guide есть много и других настроек и конфигураций, изменение которых помогут вам повысить уровень безопасности. Иногда это связано с требованиями регулирующих органов или спецификой внутренних политик организации. Поэтому обратите особенное внимание на те конфигурации, которые помечены как Site Specific, а также те, где рекомендуемые значения отличаются от дефолтных. И обязательно документируйте сделанные изменения, а также проводите регулярный аудит наиболее важных настроек.

На днях компания VMware объявила о скором обновлении своего средства NSX-T до версии 3.2. Напомним, что NSX-T - это решение для сетевой виртуализации и агрегации виртуальных сетей датацентров, работающих на базе гибридной среды гипервизоров, физических серверов и контейнеров приложений Kubernetes. О версии VMware NSX-T 3.0 мы писали в прошлом году вот тут.

Отметим, что поддержка продукта VMware NSX Data Center for vSphere заканчивается 16 января 2022 года, поэтому все партнеры и клиенты должны перевести рабочие нагрузки на VMware NSX-T. При этом могут переезжать как окружения на базе Cloud Director, так и без него - все ресурсы, описывающие этот процесс, доступны. Основной инструмент для этого переезда - это VMware NSX Data Center for vSphere to VMware NSX-T Data Center migration tool.

Давайте посмотрим, что появилось нового в VMware NSX-T 3.2.

Функции мультиоблачной безопасности

Здесь появились следующие улучшения:

1. Возможности Tapless Network Traffic Analysis (NTA)

Функции Network traffic analysis (NTA) и средства для создания песочниц интегрированы в единый NSX Distributed Firewall (DFW). Сам сервис NTA встроен в гипервизор. Вместе с функциями IDS/IPS решения NSX администраторы могут виртуализовать весь стек безопасности и устранить слепые зоны для применения политик безопасности, чтобы контролировать сетевые потоки, безотносительно того, какие физические уровни под ними лежат.

2. Сетевой экран шлюза (Gateway Firewall)

Улучшенный gateway firewall служит как программный шлюз с возможностью контроля на уровнях L2-L7, включая URL-фильтрацию и расширенные функции предотвращения угроз с возможностями анализа вредоносного ПО и сэндбоксинга.

Это расширяет функции централизованного управления безопасностью на физические нагрузки, периметр датацентра и оконечные устройства, что дает возможность реализовать концепцию east-west и north-south по защите данных под центральным управлением движка NSX Intelligence.

3. Интегрированный механизм NDR и NSX Intelligence

Теперь решение NSX Network Detection and Response (NDR) интегрировано в платформу NSX Intelligence, что позволяет решению NDR понимать сигналы от IDS/IPS, NTA и сэндбокса, чтобы идентифицировать настоящие вторжения. Также NSX Intelligence получил улучшения производительности, а также улучшения движка рекомендаций для правил фаервола.

4. Распределенная Switch-agnostic безопасность

NSX Distributed Firewall теперь поддерживает рабочие нагрузки, развернутые на распределенных группах портов (Distributed Port Groups) распределенных коммутаторов (VDS). Это позволяет реализовать фаервол NSX без внесения изменений в vSphere Distributed Switch и без конвертации портов в N-VDS, а также без развертывания сетевых оверлеев.

Улучшения сетевого взаимодействия и механизма политик

Здесь мы увидим 3 основных улучшения:

1. Работа с сетью и обеспечение безопасности для связки NSX-T и Antrea

Начиная с NSX-T 3.2, сетевые администраторы могут определить политики для Antrea в плане сетевых настроек и безопасности для контейнеров прямо из интерфейса NSX-T Manager. Политики применяются к кластерам Kubernetes на базе Antrea 1.3.1-1.2.2 с использованием interworking controller. Объекты K8s, такие как поды, пространства имен и сервисы, объединяются в инвентаре NSX-T и тэгируются, а значит их можно выбрать при настройке политик Distributed Firewall. Также NSX-T может управлять компонентом Antrea Traceflow и собирать лог-бандлы с кластеров, используя Antrea.

2. Улучшенный координатор миграции

NSX Migration Coordinator был улучшен, теперь он поддерживает определенные пользователем топологии NSX, больший масштаб развертываний и другие возможности, которые ранее не поддерживались, например, VMware Integrated OpenStack (VIO), фиксированные топологии OSPF, функции guest introspection для партнеров, которые поддерживают Migration Coordinator, а также конфигурации identity-based firewall (IDFW/RDSH).

3. Функции NSX Federation

Эти возможности впервые были представлены в NSX-T 3.0. Они позволяют через NSX Global Manager централизованно управлять распределенной виртуальной сетью в нескольких локациях, поддерживая их в синхронизированном виде с точки зрения конфигурации, политик безопасности и операционного управления. 

Теперь NSX Federation поддерживает репликацию тэгов виртуальных машин между local managers, что позволяет виртуальным машинам при восстановлении после сбоя сохранить нужные политики безопасности. Также в NSX-T 3.2 есть мониторинг состояния каналов коммуникации между global и local manager.

Улучшения настройки сети и операций

В этой категории VMware сделала 4 основных улучшения:

1. Улучшенное развертывание NSX

Теперь администраторы могут развернуть NSX-T manager и различные сценарии networking and security напрямую из клиентов vSphere. Также есть guided workflows, которые упрощают развертывание NSX Manager и настройку политик.

2. Упрощенное развертывание для NSX Advanced Load Balancer 

Установка NSX Advanced Load Balancer (ALB) теперь стала проще за счет тесной интеграции с NSX Manager. Вы можете использовать графический интерфейс NSX Manager для установки и настройки контроллеров NSX Advanced Load Balancer, после чего запустить ALB UI для настройки расширенных параметров. Также появились возможности по миграции своего решения по балансировке с NSX for vSphere на VMware NSX Advanced Load Balancer с использованием Migration Coordinator.

3. Поддержка vRealize Network Insight Support для NSX-T Federation and Firewall

Тесная интеграция между vRealize Network Insight 6.4 и NSX-T Federation позволяет улучшить сетевую видимость между разными датацентрами на базе NSX-T на разных уровнях: глобальном, региональном и уровне локального сайта. Новые возможности позволяют оптимизировать производительность и просмотр сетевых потоков VM-to-VM как в рамках одного сайта, так и между сайтами в рамках федерированной топологии. vRealize Network Insight 6.4 теперь поддерживает  NSX-T Distributed Firewall (DFW) на распределенных порт-группах (Distributed Port Groups, DVPG), что дает дополнительные возможности анализа незащищенных потоков трафика, возможности безопасности, такие как Name Space (NS) groups, а также правила распределенного фаервола на существующих группах vSphere VLAN DVPG.

4. Улучшения сетевого мониторинга и механизма решения проблем

Новые функции Edge и L3 time-series monitoring позволяют получить представления во времени для метрик Edge и L3, такие как использование CPU, памяти, диска, пакетов в секунду, байтов в секунду, packet drop rate и многое другое в NSX Manager. Это позволяет сетевым администраторам получать больше данных для анализа в историческом контексте. Функции Live Traffic Analysis в NSX Manager дают возможность производить оперативную диагностику и решение проблем в плане состояния кластера, компонентов управления, федерации, состояния транспортных узлов, distributed firewall, Edge, VPN, NAT, Load Balancing и платформы NSX Application Platform. 

Компания VMware продолжает поддерживать своих облачных партнеров, которые предлагают своим пользователям услуги аренды виртуальных машин. Мы уже писали о новостях для сервис-провайдеров на прошедшей конференции VMworld 2021, а сегодня расскажем еще об одном анонсе - возможность предложения пользователям услуг Tanzu Standard Edition.

Начиная с 25 ноября, провайдеры получили доступ к VMware Tanzu Standard - платформе, которая позволяет разработчикам развертывать и поддерживать свою инфраструктуру контейнеризованных приложений в кластерах Kubernetes. Теперь это возможно и в облаке посредством интеграции решений VMware Tanzu Standard и VMware Cloud Director (пока поддерживается версия 10.2), что позволяет создать инфраструктуру Kubernetes as-a-Service (KaaS) для мультиоблачных сред.

Теперь сервис-провайдеры имеют выбор между инфраструктурой Tanzu Kubernetes Grid, построенной на собственном дистрибутиве Kubernetes от VMware, и полностью интегрированном сервисе на платформе vSphere. Управлять всем этим можно через консоль Tanzu Mission Control.

Вот какие сервисы теперь могут предлагать провайдеры своим клиентам:

• Создание кластеров K8s
  • Развертывание кластеров
  • Служба VMware Storage service для окружений разработчиков
  • Библиотека контента (Content library) для версий Kubernetes
  • Сетевой сервис для K8s-кластеров, включая балансировку нагрузки (NSX ALB Basic), сервисы NAT и другое
  • Плагин для интерфейса Antrea Container Networking Interface (CNI)
  • Сервисы обслуживания жизненного цикла через Cluster API
• Операции с кластерами K8s
  • Привязка и управление CNCF-совместимыми кластерами K8s
  • Централизованный доступ и управление политиками
  • Служба vSphere Pod Service
  • Служба Image Registry на базе Harbor для управления версиями в контейнерном окружении
  • Возможности мониторинга состояния рабочих нагрузок через Fluent Bit, а также Prometheus и Grafana для мониторинга самой платформы
  • Управление на базе vCenter
  • Резервное копирование и восстановление пространств имен, а также запланированный бэкап
  • Возможности аудита системы и произошедших событий, включая срез кластера по производительности
  • Возможность загрузить opensource-пакеты для мониторинга через Fluent Bit, а также службу image registry через Harbor и Calico CNI

Больше интересного о решении Tanzu Standard Edition для сервис-провайдеров можно узнать на следующих ресурсах:

• Tanzu Standard Solution Brief
• VMware Tanzu Editions – Tanzu Standard
• VMware Developer Ready Cloud
• VMware Tanzu Blog

Продолжаем рассказывать об анонсах компании VMware, которые были сделаны на онлайн-конференции VMworld 2021, прошедшей этой осенью. Сегодня мы поговорим о новостях, касающихся облачных партнеров по программе Cloud Provider, которые, в свою очередь, предоставляют виртуальную инфраструктуру в аренду из облака конечным пользователям.

1. Выпуск новой версии Cloud Director 10.3

Об этом мы уже рассказывали вот в этой статье. Напомним, что Cloud Director - это основная система управления облаком, которую используют сервис-провайдеры.

Если вы еще более детально хотите узнать о новых возможностях новой версии этой платформы, посмотрите презентацию VMware Cloud Director [MCL2167].

2. Обновление VMware Cloud on Dell EMC

Доля Dell EMC на рынке оборудования для сервис-провайдеров виртуальных инфраструктур составляет 29%, поэтому VMware постоянно делает улучшения в этой сфере. С помощью VMware Cloud Foundation пользователи могут обслуживать онпремизное облако совместно с командой VMware SRE в режиме 24/7, точно так же, как это происходит и в публичных облаках, таких как VMware Cloud on AWS.

Поставщиков решений VMware Cloud on Dell EMC можно найти через VMware Cloud Partner Navigator, а обо всех последних новостях по продуктовой линейке VxRail можно узнать из доклада MCL2768S конференции VMworld.

Также теперь VMware Cloud Director поддерживается с инфраструктурой VMware Cloud Foundation, работающей на аппаратной платформе Dell EMC VxRail - таким образом, VMware поддерживает весь стек программно-аппаратных решений для построения полноценного частного облака Enterprise-уровня с поддержкой multi-tenancy:

Все это управляется через VMware Cloud Foundation SDDC Manager, а архитектура VCF/VxRail - по-сути, единственная на сегодняшний день для частных облаков, которая полностью поддерживается на всех программных и аппаратных уровнях. Более подробно об этом можно почитать здесь.

3. Расширение списка cloud endpoints.

Теперь через VMware Cloud Director и VMware Cloud Director Availability доступно еще больше интеграций для мультиоблачных сред:

Cloud Director теперь поддерживает Dell EMC vxRail под управлением VMware Cloud Foundation для публичных и частных облаков, также есть endpoint для VMware Cloud on Dell EMC (полностью управляемое со стороны VMware решение).

Кроме того, Cloud Director теперь может управлять службами Google Cloud VMware Engine в качестве endpoint для масштабирования рабочих нагрузок в облаке. Это позволяет получить возможности Google Cloud Platform для корпоративных пользователей, которые используют Cloud Director для управления мультиоблачными средами. Пока это решение находится в статусе технологического превью, но доступ к нему уже можно запросить по почте ask_cloud_director_service@vmware.com.

4. Адаптер Cloud Director для vRealize Automation

Теперь пользователи онпремизного продукта VMware vRealize Automation могут получить преимущества облачного решения VMware Cloud Director, соединив свою инфраструктуру с инфраструктурой провайдера.

5. Обновление продукта VMware Cloud Provider lifecycle Manager до версии 1.2

Теперь с помощью VMware Cloud Provider lifecycle Manager 1.2 (VCPLM) можно автоматизировать рутинные операции жизненного цикла пользователей, разрабатывая свои сценарии развертывания, обслуживания и списания систем, что позволяет сотрудникам сервис-провайдеров сосредоточиться на более высокоуровневых операциях.

6. Обновление VMware Cloud Provider Navigator

Количество предлагаемых облачных сервисов через этот портал продолжает расти, а пользователи могут получить все более персонализированные и комплексные услуги от своих поставщиков:

Более подробно об этом средстве рассказано в презентации MCL1421 прошедшего VMworld.

7. On-Demand DRaaS для VMware Cloud Disaster Recovery

Теперь службы VMware Cloud Disaster Recovery позволяют производить восстановление после сбоев по запросу (On-Demand Disaster Recovery) напрямую в облако to VMware Cloud on AWS, что повышает спектр услуг, которые провайдеры могут предложить своим клиентам.

VMware Cloud Disaster Recovery обеспечивает оркестрацию процесса создания реплик на хранилищах S3 Cloud, а также реализацию процесса восстановления инфраструктуры на стороне VMware Cloud on AWS с сохранением показателя RPO равного 30 минутам.

Здесь пользователям доступны immutable-резервные копии с поддержкой шифрования, а также forever incremental копии в целях экономии пространства, за которое пользователь платит только по мере заполнения новых емкостей.

Для использования VMware Cloud Disaster Recovery понадобятся 2 MSP-контракта - на сервис и на публичное облако VMware Cloud on AWS. К сожалению, пока решение VMware Cloud Disaster Recovery не совместимо с VMware Cloud Director.

Сценарии на картинке ниже показывают, как облачные провайдеры могут предлагать сервис аварийного восстановления в публичное облако своим клиентам:

Как мы видим, тут доступны различные комбинации решений, включая замену существующей схемы, а также сосуществование с текущими endpoint-конфигурациями. На схеме обозначения читаются так:

• VMC on AWS – VMware Cloud on AWS
• VCD – VMware Cloud Director
• VCDA – VMware Cloud Director Availability
• VCDR – VMware Cloud Disaster Recovery

8. Возможность миграции VMware NSX Data Center for vSphere на VMware NSX-T Data Center

Так как поддержка VMware NSX Data Center for vSphere заканчивается 16 января 2022 года, все партнеры должны перевести рабочие нагрузки на VMware NSX-T. При этом могут переезжать как окружения на базе Cloud Director, так и без него - все ресурсы, описывающие этот процесс, доступны. Основной инструмент для этого переезда - это VMware NSX Data Center for vSphere to VMware NSX-T Data Center migration tool.

Если сервис-провайдер не хочет переезжать, он может купить Extended Support pack, но работать он будет только до 16 января 2023 года. Более подробно о процессе миграции написано вот тут, а также вот в этой статье на блогах VMware.

Многим из вас знакомы продукты компании StarWind, предназначенные для создания отказоустойчивых хранилищ под различные платформы виртуализации. Сегодня мы поговорим о том, как настраивать аутентификацию доступа к хранилищам через протокол CHAP в решении StarWind Virtual SAN...

Компания VMware объявила о выпуске новой версии VMware Cloud Director App Launchpad (ALP) 2.1. Этот продукт позволяет клиентам облаков использовать приложения и не думать о нижележащей инфраструктуре. Сервис-провайдеры с помощью этого средства могут предложить маркетплейс для пользователей, где они выбирают приложения для использования на базе контейнеров или виртуальных машин. О прошлой версии этого продукта мы писали вот тут.

Давайте посмотрим, что нового в VMware Cloud Director ALP 2.1:

1. Улучшения управления каталогом

Теперь ALP 2.1 создает каталоги от имени сервис-провайдера. Это позволяет автоматизировать создание каталога для провайдера и устраняет проблемы с подключением и безопасностью, так как ALP и Cloud Director находятся за одним фаерволом и в той же сети провайдера. Это означает, что сервис-провайдеры могут безопасно скачивать приложения с VMware Marketplace и публиковать их в своих каталогах VMware Cloud Director, без необходимости делать входящий доступ для VCD от IP-адресов маркетплейса VMware.

Так это работало до нововведения:

А теперь это работает вот так:

Еще одно существенное нововведение в этой категории - автоматизированное развертывание рабочих нагрузок в контейнерах через VMware Cloud Director Container Service Extension (CSE) для кластеров Kubernetes. Раньше пользователям приходилось вручную устанавливать адреса для кластеров CSE при развертывании рабочих нагрузок. Теперь же ALP 2.1 автоматически обнаруживает кластеры CSE и выводит их список для пользователей.

2. Улучшения обслуживания

Сервис-провайдеры теперь могут получить любую информацию о пользователе, которую они хотят знать, до того, как он развернет приложение. Также можно определять кастомные поля любого типа, видимые для пользователя на странице запуска приложения.

Также провайдеры могут создавать шаблоны по умолчанию и кастомные шаблоны для загружаемых приложений, а также определять видимость кастомных полей для пользователей разных категорий.

Администраторы Tenant Admins могут брендировать пользовательский дэшборд логотипом организации, картинками и приветственным сообщением. Также они могут просматривать и анализировать данные использования приложений за настраиваемый промежуток времени.

Для пользователей-клиентов провайдера ALP 2.1 имеет несколько улучшений в юзабилити:

• Можно фильтровать и искать приложения по имени в каталоге:

Рабочие нагрузки можно фильтровать по имени, типу и статусу:

Также новые приложения можно запускать напрямую со вкладки "My Applications".

Более подробно о новых возможностях рассказано на странице документации по продукту. Скачать VMware Cloud Director App Launchpad (ALP) 2.1 можно по этой ссылке. Процедура обновления описана тут.

Недавно мы писали о продукте NAKIVO Backup & Replication, который является одним из лидеров в сфере решений для резервного копирования и защиты данных виртуальной инфраструктуры. Мы рассказали об основных его возможностях и областях применения, а сегодня мы подробно остановимся на его использовании при защите от программ-вымогателей (Ransomware)...

Компания VMware обновила свои основные настольные платформы виртуализации, выпустив финальные версии VMware Fusion 12.2 и VMware Workstation 16.2. Напомним, что о прошлой мажорной версии Fusion 12 мы писали вот тут, а о Workstation 16 - вот тут.

Давайте посмотрим, что нового появилось в этих небольших обновлениях.

Итак, в VMware Fusion 12.2 появились следующие фичи:

1. Плавный переход к полной поддержке Windows 11

Пока полноценной поддержки Windows 11 еще нет, но технически Fusion уже полностью готова исполнять эту ОС в виртуальной машине, поэтому соответствующий тип ОС при выборе теперь называется "Windows 10 and Later".

Теперь на Intel-маках Windows 11 будет полноценно работать с VMware Tools 11.3.5, а также при установке ОС будут пройдены все необходимые проверки совместимости касательно минимальных требований.

2. Экспериментальная поддержка виртуального модуля vTPM

VMware продолжает развивать виртуальный модуль шифрования vTPM, в котором в этом релизе представлена новая модель шифрования, намного меньше влияющая на производительность. Для использования этого экспериментального устройства просто добавьте в конфигурационный vmx-файл виртуальной машины на Fusion следующую строчку:

managedvm.AddVTPM="software"

Использование такого модуля позволяет не применять полное шифрование виртуальных машин, которое используют некоторые пользователи, и которое очень сильно влияет на производительность.

3. Работа над поддержкой архитектуры Apple Silicon

Об этом мы подробно писали в мае этого года. VMware по-прежнему ведет работу над Public Tech Preview, который умеет исполнять ОС Linux и BSD aarch64. Все больше дистрибутивов nix-систем включают в себя Open VM Tools и ядро Linux 5.14 kernel, которые могут работать в виртуальных машинах на базе аппаратной платформы Apple Silicon.

4. macOS 10.15 Catalina больше не поддерживается

Теперь нужно использовать macOS, начиная с версии 11.0 (Big Sur).

Для обновления продукта просто выберите "Check for Updates" в меню VMware Fusion, либо скачайте новую версию по этой ссылке.

В VMware Workstation 16.2 появились следующие возможности:

1. Плавный переход к полной поддержке Windows 11

Пока полноценной поддержки Windows 11 еще нет, но технически Workstation уже полностью готова исполнять эту ОС в виртуальной машине (с точки зрения Secure Boot, vTPM, минимальных требований CPU/RAM), поэтому соответствующий тип ОС при выборе теперь называется "Windows 10 and Later".

В качестве хостовой системы Windows 11 работает сейчас так же хорошо, как она работала и с прошлой версией - Windows 10.

2. Экспериментальная поддержка виртуального модуля vTPM

VMware продолжает развивать виртуальный модуль шифрования vTPM, в котором в этом релизе представлена новая модель шифрования, намного меньше влияющая на производительность. Для использования этого экспериментального устройства просто добавьте в конфигурационный vmx-файл виртуальной машины на Workstation следующую строчку:

managedvm.AddVTPM="software"

Использование такого модуля позволяет не применять полное шифрование виртуальных машин, которое используют некоторые пользователи, и которое очень сильно влияет на производительность.

3. Убрана функция "Shared VM"

Эту возможность анонсировали больше года назад, она позволяла расшарить виртуальную машину через сеть, как будто она работает на хосте ESXi. Однако ввиду появляющихся артефактов в UI VMware пока убрала поддержку этой фичи (ВМ, настроенные на авто-старт в этом режиме также не будут работать после этого обновления).

4. Поддержка рендера Vulkan для модулей Intel, AMD и NVIDIA GPU на платформе Linux

Workstation 16.2.0 Pro поддерживает рендер Vulkan в ОС Linux на базе карточек Intel, NVIDIA и AMD. Рендер Vulkan поддерживает движок Direct3D 11 (и более ранние), а также OpenGL 4.1 (и более ранние) в гостевой ОС. Поддержка этого рендера ограничена следующими GPU:

• Intel Skylake и более поздние (например, Kaby Lake и Ice Lake)
• AMD RDNA/NAVI14 и более поздние (нужно использовать драйвер AMDVLK)
• Nvidia Turing и более поздние (например, серия RTX) - для более ранних Workstation будет использовать legacy OpenGL renderer.

Для обновления продукта просто выберите "Check for Updates" в меню VMware Workstation, либо скачайте новую версию по этой ссылке.

В рамках конференции VMworld 2021 было сделано не только немало анонсов новых технологий и инициатив VMware, но и объявлено о выпуске новых версий некоторых продуктов. В частности, VMware сделала доступной для загрузки новую версию платформы vRealize Automation 8.6, которая предназначена для автоматизации рутинных операций в облаке на базе VMware vSphere. О прошлой версии vRA 8.5 мы детально рассказывали вот тут.

Давайте посмотрим, что нового в vRA 8.6:

1. Поддержка VMware Cloud Director

Теперь доступен Cloud Account, который открывает интеграцию с решением Cloud Director. Теперь внутри vRA поддерживаются такие объекты, как Virtual Data Center, сети, изменение политик хранилищ и конфигураций ВМ, образы, сами ВМ и их диски и многое другое. Также со стороны vRA можно выполнять day-2 операции, такие как включение ВМ, снапшоты и управление дисками. Развертывание доступно через шаблоны Cloud Templates, а операции жизненного цикла можно осуществлять как через vRA, так и через VCD.

Более подробно о поддержке Cloud Director написано в этой статье.

2. SDDC-модули SaltStack Config для vSphere, VMC и NSX

Новые модули SaltStack SDDC теперь доступны как Open Source. Они сфокусированы на продуктовой линейке vSphere, VMware Cloud on AWS и NSX. Возможности работы с ними включают в себя различные сценарии операций day-0 и day-2, такие как создание SDDC, просмотр правил безопасности VMC, настройка NSX-T manager, конфигурация кластера vSphere и многое другое. Эти модули доступны на GitHub и могут быть использованы всеми пользователями Salt и SaltStack Config.

Более подробно об этом рассказано здесь.

3. Кастомные ресурсы с действиями ABX Actions

Теперь можно создавать Custom Resources на базе действий ABX extensibility в рамках операций жизненного цикла и контекстных действий day-2. До этого администраторы были ограничены только существующим инвентарем vRO для этого. Теперь для новых действий потребуется новый плагин или динамический тип, чтобы работать с новыми типами ресурсов. С помощью этой фичи можно создавать, читать, обновлять и удалять действия жизненного цикла и day-2 actions за счет создания ABX actions.

Об этой возможности также есть подробная статья вот тут.

4. Рабочее пространство Kubernetes в Code Stream

Рабочее пространство (Workspace) в отображении Code Stream представляет собой sandbox-окружение, которое позволяет исполнять задачи Continuous Integration tasks из пайплайна. С помощью этой функции пользователь может выбрать Kubernetes endpoint и запустить исполнение пайплайна в Kubernetes, либо же в Docker endpoint.

Более подробно об этом написано тут.

5. Dynamic vRO inputs в шаблонах Cloud Templates

В этом обновлении пользователи могут использовать dynamic inputs в нативном окружении шаблонов vRA Cloud Templates. Нужно просто выставить внешний источник ввода, добавить существующее действия и включить динамические значение на базе vRO workflow.

Как это делается в деталях вы можете узнать вот тут.

6. Настройки IPAM в шаблоне Cloud Template

Настройки IPAM, включая адреса шлюзов, домена, доменов DNS и DNS search - теперь настраиваются через шаблон Cloud Template. Эти настройки хранятся как часть machine schema и NIC properties. Эта опция доступна для типов машин vSphere, где используется статическая IP-адресация.

7. Политика Resource quota policy для изменений в операциях day-2

Политика квот ресурсов теперь применяется к изменениям day-2, касающихся CPU, памяти или хранилища, включая действия resize. Использование ресурсов обновляется в соответствии с изменениями и применяется на базе выставленной квоты на уровне Project или Org.

8. Сети vSphere теперь включены в onboarding plan

Рабочий процесс Workload onboarding теперь поддерживает сети vSphere, привязанные к объектам deployments. До этого поддерживалась только IP-информация и IP allocation/de-allocation. Теперь все сети vSphere видимы на deployment canvas, а конфигурации могут включать в себя day-2 операции в рамках процесса онбординга.

9. Добавлена роль Project Supervisor для проектов

Для объектов Projects добавлена новая роль Project Supervisor, он позволяет ускорить процесс утверждения (Approval). До этого нужно было неадминистративным пользователям применять специальную политику approval policy. Теперь специальный пользователь Project Supervisor может делать утверждение deployments, когда данная роль настроена в политике.

10. Изменение сетевых настроек виртуального модуля vRA appliance

Теперь у вас есть возможность изменить IP-адрес виртуального модуля vRA. Эта потребность часто возникает в сценариях восстановления после сбоя, особенно при использовании Site Recovery Manager. Теперь vRA поддерживает восстановление без использования растянутых (stretched) сетей.

Более подробно о новых возможностях VMware vRealize Automation 8.6 можно узнать из Release Notes. Скачать vRA 8.6 можно по этой ссылке.

Компания VMware на днях объявила о доступности для заказчиков решения VMware Cloud on AWS Outposts. Напомним, что механизм AWS Outposts позволяет заказчикам использовать стандартные сервисы AWS, как будто они работают в облаке, но реально исполнять их на своем оборудовании. Это позволяет получить все сервисы AWS SDDC в своем датацентре, но при этом платить по модели повременного использования ресурсов AWS. Об этом было объявлено еще в 2018 году, но до финальной доступности дело дошло только сейчас.

Такое решение может пригодиться в отраслях, где существуют высокие требования к задержкам проведения операций (latency), что требует локального исполнения вычислительных ресурсов, например, в телекоме, высокочастотной биржевой торговле, промышленной автоматизации, финансовых сервисах, ИТ-системах здравоохранения и других приложениях.

Ключевыми элементами инфраструктуры VMware Cloud on AWS Outposts являются:

• Инфраструктура VMware Software-Defined Data Center (SDDC)
• Платформа виртуализации vSphere
• Инфраструктура хранения VMware vSAN
• Сетевая инфраструктура VMware NSX
• Средства управления VMware vCenter
• Решение VMware HCX для миграции онпремизных систем в облако
• Стойки 42U с полностью собранным комплектом оборудования (источники питания, коммутаторы), которое устанавливается сотрудниками AWS
• Выделенные bare-metal EC2-инстансы на базе оборудования Amazon Nitro с SSD-хранилищами, развернутые в инфраструктуре AWS Outposts
• Техническая поддержка VMware Global Support

VMware Cloud on AWS Outposts поддерживает инстансы i3en.metal instance (кстати, на них сейчас дают скидки). Эти инстансы, работающие на оборудовании со вторым поколением процессоров Intel Xeon, оптимизированы для приложений, требующих высокую скорость случайных операций ввода-вывода (I/O) при работе с большими объемами данных, которые оптимизируются средствами VMware VSAN Compression.

Инстансы AWS Outposts i3en.metal предоставляют:

• Сырую емкость хранилищ 45.84 TiB (50 TB) на хост с дополнительной емкостью кэша 6.55 TiB, который работает на базе устройств NVMe SSD.
• В зависимости от настроек RAID и политик FTT, такой инстанс может давать до 34 TiB полезной емкости.
• Поддержка до 96 логических ядер или такого же количества vCPU для приложений, требовательных к ресурсам процессора.
• 768 GiB (825 GB) оперативной памяти.

Пользователи могут выбрать от 3 до 8 хостов на стойку. Также идет некоторый запас емкости для операций с хостами, Elastic DRS scale-out и управления жизненным циклом инфраструктуры.

Есть 2 момента по реализации сетевой инфраструктуры:

1. Организация соединения Service Link Connection

Все аутпосты требуют высокоскоростное соединение с AWS ближайшего региона. Скорость соединения должна быть минимум 1Gb с latency до 150 мс. Сервисное соединение - это набор VPN-соединений, которые используются для коммуникации с основным датацентром региона. Опции подключения включают в себя AWS Direct Connect через частный или публичный Virtual Interface (VIF), либо через интернет вашего сервис-провайдера.

VMware Cloud on AWS Outposts предоставляет соединение с региональными службами AWS через Elastic Network Interface (ENI) или VMware Transit connect. Передача данных VMware Cloud on AWS Outposts в родительский датацентр VMware Cloud on AWS бесплатна, это расширение соответствующей Availability Zone.

2. LGW – Local Gateway

Этот компонент обеспечивает общение между онпремизной инфраструктурой и окружением VMware Cloud on AWS Outposts, которое также расположено на площадке заказчика:

VMware NSX обеспечивает коммуникацию между всеми компонентами этой среды, а с помощью VMware HCX можно перемещать рабочие нагрузки в VMware Cloud on AWS Outposts.

Заказывать ресурсы аутпостов можно в стандартной консоли VMware Cloud. С точки зрения поддержки, первичной точкой контакта выступает VMware. Любые аппаратные проблемы также решает VMware, коммуницируя с AWS, которые отвечают за исправность оборудования.

Более подробно о VMware Cloud on AWS Outposts можно почитать на странице решения.

На днях компания VMware объявила о релизе новой версии решения Object Storage Extension 2.1 (OSE). Напомним, что это фремворк для поддержки хранилищ S3 в инфраструктуре сервис-провайдеров, которые работают на базе VMware Cloud Director. Год назад мы упоминали о выпуске версии 2.0, а сегодня расскажем, что нового там появилось за это время.

Итак, новые возможности Object Storage Extension 2.1:

1. Резервное копирование и восстановление по запросу для Kubernetes (оно же K8s B&R)

VMware Cloud Director Object Storage Extension теперь имеет встроенные возможности Kubernetes Backup & Restore (K8s B&R), которые доступны непосредственно в VMware Cloud Director. Теперь облачные провайдеры могут защищать не только виртуальные машины, но и рабочие нагрузки контейнеризованных приложений. Возможности K8s B&R построены на базе решения Velero, которое использует S3-протокол для хранения резервных копий, чтобы защитить данные на персистентных томах.

Резервное копирование изначально поддерживает инфраструктуру большого количества клиентов (multi-tenancy), которые работают с кластерами TKG, CSE-кластерами и отдельными K8s-инсталляциями под управлением Container Service Extension 3.0. Также при бэкапе используется end-to-end шифрование.

Подробнее о новых функциях резервного копирования рассказано тут.

2. Доступ к облачным политикам хранения Cloudian

Политики объектных хранилищ Cloudian позволяют обеспечивать защиту и распределение хранилищ между потребителями в рамках организации. С помощью простых правил облачные провайдеры могу дать пользователям возможности создавать свои бакеты и объекты. Начиная с версии OSE 2.1, клиенты, которые используют Cloudian, могут создавать кастомные политики хранилищ непосредственно из OSE. Более подробно об этом написано тут.

3. Улучшенная синхронизация бакетов и вывод объектов

Для клиентов с несколькими площадками бакеты теперь агрегируются в рамках одного представления в консоли VMware Cloud Director. Облачные провайдеры могут наблюдать за статусом синхронизации бакетов своих клиентов. Также на глобальном уровне доступна опция синхронизации бакетов, которую могут включить администраторы сервис-провайдера, чтобы убедиться, что все мультисайтовые бакеты синхронизированы (включение этой фичи можно также поставить в планировщик). Более подробно об этом тут.

4. AWS S3 Archived Object Restoration

Amazon S3 требует, чтобы каждый объект был ассоциирован с классом хранилищ в зависимости от варианта использования. Из доступных четырех классов пользователи и администраторы облачных провайдеров могли получать доступ к Standard и Intelligent классам. Теперь же клиенты могут получить доступ к классам Glacier и Glacier Deep (но сначала нужно включить функцию restore для объектов). Более подробно VMware рассказала об этом здесь.

5. Управление на базе ролей (Role-based Access Control, RBAC)

Теперь можно использовать кастомные роли, чтобы назначить их пользователям клиентов для управления объектами vApps, Catalogs и Kubernetes B&R. В новой версии есть встроенный список удобного выбора пользовательских прав, с помощью которого администраторы облачных провайдеров (или администраторы клиентов) могут просто ограничить возможности отдельных пользователей. Детально об этом написано тут.

6. Улучшенные функции управления для ресурсов VMware Cloud Director - vApps, VM, Catalogs

В прошлой версии OSE администраторы имели ограниченную видимость при импорте и экспорте истории vApp. Теперь же вся история доступна в виде полного списка происходивших событий. Также в интерфейсе произошло несколько изменений - новое меню для создания и восстановления виртуальных приложений vApp теперь бесшовно интегрировано в консоль Cloud Director. Подробнее об этом можно почитать по этой ссылке.

Скачать VMware Object Storage Extension 2.1 можно вот тут. Есть также несколько интересных документов и материалов по продукту:

• Release Notes
• Upgrading to VMware Cloud Director Object Storage Extension 2.1
• OSE 2.1 Solution Overview
• OSE 2.1 Reference Design Whitepaper
• OSIS Development Guide

Давно мы не писали о продуктах компании NAKIVO - одного из лидеров в сфере резервного копирования и защиты данных виртуальной инфраструктуры. Недавно компания выпустила обновление NAKIVO Backup & Replication v10.4. Напомним, что мы писали о версии NAKIVO B&R 10 чуть больше года назад. С тех пор функциональность продукта существенно улучшилась - это полноценное Enterprise-решение, которое получило функции защиты от программ-вымогателей и...

Летом этого года компания VMware запустила сервис Hands-on Labs Request, который позволяет запросить виртуальные окружения и лабораторные работы Hands-on Labs (HoL) в различных целях, например, в целях проведения собственного мероприятия партнерами или внутреннего воркшопа для сотрудников.

Ранее этот сервис назывался Labs In-a-Box и имел меньше возможностей, теперь вот с помощью Labs Request можно зарезервировать мощности для проведения лабораторных работ из огромного онлайн-каталога VMware. Помимо обычных лабораторных работ, доступны также опции тренингов с инструктором, а также материалы цикла VMware Odyssey о продуктовой линейке компании.

Итак, чтобы начать, нужно войти через портал MyVMware, после чего станет возможным создание нового события (вы также можете создать копию из прошлого ивента):

После определения основных параметров события, можно указать типы лабораторных работ и количество мест, под которые будут подготовлены виртуальные облачные окружения:

Далее всем участникам события будет выслано приглашение в календарь со ссылкой на подключение в назначенное время. Сам план мероприятия будет отображаться в общем календаре:

Запросить тестовую лабораторию VMware HoL Request можно по этой ссылке.

В августе компания VMware выпустила новую версию продукта Cloud Director Availability 4.2.1, который предназначен для создания резервной инфраструктуры в одном из публичных облаков сервис-провайдеров на основе VMware Cloud Director (так называемая услуга Disaster-Recovery-as-a-Service, DRaaS). Напомним, что о предыдущей версии этого продукта 4.1 мы писали в декабре прошлого года вот тут.

Основная новая возможность продукта - это автоматическое расширение сети Layer 2 в облако.

Теперь Cloud Director Availability 4.2.1 позволяет расширить Layer 2 network в облако, как для инсталляций VMware Cloud Director на базе VMware NSX-T Data Center (это появилось еще в версии 4.2), так и на базе NSX Data Center for vSphere.

Это позволит облачным провайдерам, использующим VMware NSX, растянуть онпремизные сети клиентов на свои облака. После этого они смогут предложить клиентам бесшовный путь миграции в их облака с использованием обеих версий решения NSX.

Для использования этих возможностей виртуальные модули VMware Cloud Director Availability нужно обновить на версию 4.2.1. Что касается версий VCD и NSX, то нужно использовать VMware Cloud Director 10.x и NSX Data Center for vSphere 6.4.10 или более поздние.

При этом тут есть следующие ограничения:

• Только ести Routed Org VDC с типом интерфейса Subinterface могут мыть использованы как Server networks, которые присоединяются к Trunk-интерфейсу NSX Data Center for vSphere Edge.
• Сеть Guest VLAN должна быть деактивирована. Если ранее она была хоть раз активирована, то нужно ее пересоздать и снова деактивировать при создании.
• После создания сессии L2 VPN Server выбранные сети Server Networks уже нельзя менять (если нужно поменять - их нужно пересоздать).
• Для больших инсталляций (50 серверов vCenter и более) есть проблемы с NSX Data Center for vSphere, когда Edge VM падают с kernel panic.
• Для инсталляций Edge Gateway нельзя менять настройки после первоначальной установки. Если вы меняете, например, тип с Compact на Large, то нужно удалить конфигурацию IPSec и пересоздать сессию L2 Server Session.

Итак, чтобы включить растянутую конфигурацию, вам нужно на стороне облака:

1. Зарегистрировать NSX Data Center for vSphere Manager в интерфейсе VMware Cloud Director Availability и принять сертификат для создания траста:

2. Создать сессию L2 VPN Server, указав IP-адреса и сети, используемые для растягивания. Эту операцию может провести как облачный провайдер, так и Org Admin со стороны клиента:

Как и в случае NSX-T Data Center, для растягивания сети в NSX Data Center for vSphere нужно использовать VMware NSX Edge (он же NSX Autonomous Edge), там есть простой мастер из нескольких шагов:

Эта функциональность не требует от пользователей дополнительных затрат, но несет дополнительную полезность для сервис-провайдеров, которые теперь могут предложить новое качество услуг и дать клиентам возможность использовать больше ресурсов своего облака, упростив при этом их администрирование.

Руководства по апгрейду на новую версию для клиентов и сервис-провайдеров приведены здесь:

• VMware Cloud Director Availability Upgrade Guide for Providers
• VMware Cloud Director Availability Upgrade Guide for Tenants

Скачать Cloud Director Availability 4.2.1 можно по этой ссылке.

В последнее время в продуктах VMware часто находят различные уязвимости, а хакеры по всему миру разрабатывают различные руткиты и утилиты для взлома инфраструктуры VMware vSphere и серверов ESXi. В связи с этим многие администраторы хотели бы отключить неиспользуемые плагины, которые есть в VMware vCenter. Совсем недавно появились следующие оповещения о проблемах с безопасностью (VMware Security Advisories, VMSA), которые касаются плагинов:

• CVE-2021-21972 - VMSA-2021-0002 (плагин vRealize Operations Manager)
• CVE-2021-21985 - VMSA-2021-0010 (плагин Virtual SAN Health Check)
• CVE-2021-21986 - VMSA-2021-0010 (плагины Virtual SAN Health Check, Site Recovery, vSphere Lifecycle Manager и VMware Cloud Director Availability)

Подробно об отключении плагинов у VMware написано в KB 83829. Приведем здесь данную процедуру вкратце.

В конфигурационный файл на сервере vCenter вам нужно будет добавить одну или несколько следующих строчек, в зависимости от плагина, который вы хотите отключить:

Чтобы отключить сразу все указанные плагины, нужно будет добавить следующий текстовый блок:

<PluginPackage id="com.vmware.vrops.install" status="incompatible"/>

<PluginPackage id="com.vmware.vsphere.client.h5vsan" status="incompatible"/>

<PluginPackage id="com.vmware.vrUi" status="incompatible"/>

<PluginPackage id="com.vmware.vum.client" status="incompatible"/>

<PluginPackage id="com.vmware.h4.vsphere.client" status="incompatible"/>

Давайте теперь посмотрим, какие плагины включены по умолчанию на всех серверах vCenter после установки (Default), а какие устанавливаются и включаются только после установки соответствующего продукта (Product):

Итак, чтобы отключить плагины, вам нужно:

• Подключиться к серверу vCenter Server Appliance (vCSA) по SSH как root
• Сделать резервную копию файла, например, командой:
  cp -v /etc/vmware/vsphere-ui/compatibility-matrix.xml /etc/vmware/vsphere-ui/compatibility-matrix.xml.backup
• Открыть этот файл в текстовом редакторе командой:
  vi /etc/vmware/vsphere-ui/compatibility-matrix.xml
• Добавить туда соответствующую строчку конфигурации из таблицы выше вот в этом месте (раздел pluginsCompatibility):

• Сохранить файл с помощью команды vi:
  :wq!
• Перезапустить сервисы vsphere-ui:
  service-control --stop vsphere-ui
service-control --start vsphere-ui

Если вы все еще используете VMware vCenter for Windows, то указанную процедуру нужно проделать в следующем файле (не забывайте сделать его бэкап):

C:\ProgramData\VMware\vCenterServer\cfg\vsphere-ui\compatibility-matrix.xml

Делается это в том же месте, что и для матрицы совместимости в vCSA:

После этого также перезапускаем службу vsphere-ui для Windows:

C:\Program Files\VMware\vCenter Server\bin> service-control --stop vsphere-ui
C:\Program Files\VMware\vCenter Server\bin> service-control --start vsphere-ui

В том, что плагины отключены вы сможете убедиться в интерфейсе vSphere Client в разделе Administration > Solutions > client-plugins:

Ну и для тех, кому удобнее воспринимать руководство в видеоформате, компания VMware сделала ролик на эту тему:

Компания VMware выпустила обновление своего решения HCX 4.2, предназначенного для миграции с различных онпремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на платформе VMware vCloud. Напомним, что о возможностях прошлой версии этого продукта мы писали вот тут.

Давайте взглянем на новые фичи VMware HCX 4.2:

1. Оценка времени миграции в реальном времени

Теперь примерное время, оставшееся до конца процесса миграции на базе vMotion, показано на экране задач миграции:

Тут же показывается и время до конца задачи RAV (Replication Assisted vMotion):

2. Предиктивная оценка миграций RAV (Replication Assisted vMotion) 

Используя методики машинного обучения, HCX позволяет оценить комплексную задачу миграции RAV по клику в интерфейсе управления миграциями. Предиктивная оценка вычисляется для RAV и Bulk migrations, например, для группы ВМ (Mobility group):

3. Поддержка OS Assisted Migration (OSAM) для HCX for VMware Cloud

HCX Assisted Migration позволяет автоматизировать процесс миграции с не-vSphere гипервизоров на платформу VMware ESXi. Теперь задачи OSAM можно запустить в облаках VMware Cloud on AWS или Dell EMC.

4. Поддержка кастомных атрибутов (Custom Attributes) для миграций Bulk, RAV и Cold.

Теперь опция Migrate Custom Attributes есть в разделе Extended Options для миграций типа Bulk, RAV и Cold. Значения, ассоциированные с этими атрибутами, теперь учитываются в процессе миграции.

5. Улучшения HCX для VMware Cloud Director / NSX-T 

Этот релиз HCX поддерживает VMware Cloud Director версий 10.2 и 10.3 совместно с решением VMware NSX-T 3.1. Сайт назначения должен иметь один сервер vCenter вместе с решением NSX-T.

Попробовать продукт VMware HCX 4.2 можно на его странице, а посмотреть полный список нововведений можно в Release Notes.

При поддержке Антона Гостева сотрудники отдела маркетинга компании Veeam Software (а это, напомним, производитель средств для резервного копирования виртуальных инфраструктур номер 1) запустили конкурс «Обгони Гостева».

Неофициально конкурс стартовал внутри команды Veeam в феврале этого года. В своей рассылке на форуме Гостев рассказал об установке системы резервного копирования Veeam, которая показала максимальную производительность, достигающую 11.4 ГБ/с. Коллеги делились цифрами, которые встречали в своей практике, и искали новые данные, которые побьют цифры Гостева. Теперь в Veeam решили сделать этот конкурс публичным - ищется самая быстрая инфраструктура резервного копирования Veeam в России!

Участвуйте и расскажите о конкурсе коллегам. Перед участием прочитайте ответы на вопросы об условиях конкурса. Самые интересные случаи Veeam соберет и опубликует в статье. Три самых быстрых результата получат призы:

• Электросамокат XIAOMI
• Проектор Xiaomi Mi Smart
• Умная колонка Яндекс.Станция

Размещать результаты можно в Facebook или Twitter с хештегом #BeatTheGostev. Публикации с большим количеством лайков получат также шанс выиграть дополнительный секретный приз!

Конкурс продолжится до 30 сентября включительно, после чего будут подведены итоги. Кстати, скорость 11,4 ГБ/с для системы резервного копирования не является минимальным требованием для участия в конкурсе.

Участвовать!

Вильям Лам рассказал о том, как быстро и просто дать пользователям клиента VMware vSphere Client разрешения для просмотра пространств имен (namespaces) кластера vSphere with Tanzu.

Соответствующее разрешение нужно добавить в настройках Single Sign-On клиента:

Single Sign On->Users and Groups-> вкладка Groups

Находим там группу ServiceProviderUsers на второй странице и добавляем туда пользователей, которым мы хотим дать разрешение на просмотр неймспейсов:

После этого пользователю надо разлогиниться и залогиниться снова, а для просмотра пространств имен vSphere with Tanzu будет достаточно базовой роли Read Only для vSphere, которую можно дать разработчику (никаких изменений в конфигурацию чего бы то ни было такой пользователь внести не сможет):

Для пользователей и групп из Active Directory все работает точно таким же образом.

В середине июля компания VMware выпустила обновление своей главной платформы для виртуализации и доставки десктопов и приложений VMware Horizon 8 (2106). Напомним, что год назад о версии Horizon 2006 мы писали вот тут.

Давайте посмотрим, что нового появилось в Horizon 8 / 2106:

Основные улучшения

• Поддержка Horizon 7.10 и 7.13 была расширена до 17 марта 2022 и 15 октября, соответственно
• Новые рекомендации о Horizon Agent говорят о том, что теперь не нужно переустанавливать Horizon Agent для апгрейда VMware Tools, если вы соблюдаете условия interop matrix

Обновления платформы

• Поддержка 20 тысяч сессий на один модуль Pod
• Поддержка миграции VMware Update Manager для порт-групп с NSX VDS на NSX CDS
• Дополнительные REST API endpoints, которые дают функции федерации доступа, Event DB API, поддержку RBAC через REST API и многое другое

Блокирование функций снимков экрана

Теперь для сессий десктопов Horizon администраторы могут отключать функцию снимков и записи экрана, что могло привести к краже данных со стороны пользователей. Опция поддерживается только на Windows-агентах. Делается это путем установки значения 1 в следующем ключе реестра:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Vmware, Inc.\Vmware VDM\Agent\Configuration\Screen-capture Blocking

Пока для HTML5-доступа она не поддерживается, но сам этот HTML5-доступ можно просто отключить. Блокируются только снимки через View Client, а для их отключения в самой гостевой ОС нужно использовать рекомендации Microsoft.

Мгновенные клоны

Теперь Sysprep можно использовать для объектов Instant Clones без родительских ВМ. Это может привести к падению скорости развертывания и большему числу перезагрузок. Зато у вас будет новый SID и такая же функция, которая есть и у связанных клонов.

Здесь появилось несколько значимых улучшений:

• Выбор типа vCenter для Cloud Burst - теперь можно выбирать способ управления онпремизными ресурсами Cloud Burst, которые должны удовлетворять требованиям 120 мс между агентами и Connection Server. Таким образом, вы можете использовать vCenter вашего стороннего облачного датацентра для управления ресурсами Horizon через Connection Server. Теперь нет необходимости развертывать Pods в публичном облаке только под средства управления.

• Возможность постоянного доступа к приложениям (Forever Application Sessions) - это нужно для таких сервисов, как онлайн-дэшборды, трекинг состояния (например, пациентов), тикеры акций и т.п. Эти сессии можно настроить на уровне пула/фермы или в глобальных настройках. Они поддерживают аутентифицированных пользователей на Windows и Linux клиентах.
• При создании пулов Full Clone и Managed Manual Desktop можно выбрать разрешения 5К и 8К для клиентов Blast. Максимум можно использовать 2 монитора. Для PCoIP поддерживается только 4К.

• Новые способы аутентификации для Untrusted Domains:
  • SAML
  • True Single Sign-On
  • Smart card

В новой версии коннектора есть следующие нововведения:

• Теперь можно иметь несколько узлов stateless connector. Horizon Cloud Connector служит как узел для контейнеров Kubernetes, которые выполняют критические сервисы Horizon.
• Service-level fault tolerance - теперь для сервера лицензий работают функции непрерывной доступности.
• Теперь для лицензий поддерживаются SNMP traps, такие как проблемы с синхронизацией и нотификации о событиях жизненного цикла.

• Windows Agent - он получил поддержку Windows Server 2022, а также улучшения механизма сбора данных, которые используются для мониторинга и траблшутинга. Data collection logging устанавливается по умолчанию и может быть включен через ключ реестра.
• Linux Agent -тут сразу несколько новых возможностей:
  • Linux Smartcard redirection - поддержка этого механизма доступна на десктопах Red Hat Enterprise Linux со включенным Security-Enhanced Linux.
  • Digital watermark - поддержка водяных знаков для сессий Linux, что позволяет защищать интеллектуальную собственность.
  • Поддержка Red Hat Enterprise Linux 8.4 (Workstation и Server), а также CentOS 8.4.

Тут появились следующие вещи:

• Поддержка Xbox One для Windows-клиентов
• Возможность изменять audio sample rate, которая сохраняется между сессиями
• Возможность использовать 6 мониторов в режиме 4К
• Возможность использовать GPU encoding для режима session collaboration на Windows 2004 и более поздних

Также появились улучшения Copy/Paste - теперь можно использовать Clipboard Redirection для отключения и включения операций copy-paste в рамках сессии:

Кроме того, в этой категории есть дополнительные улучшения:

• Поддержка 48khz аудио через RTAV (по умолчанию 16khz)
• Улучшения copy/paste для медленных сетей
• Эмуляция кэширования сертификатов смарт-карт для не-Windows клиентов
• Упрощенный мониторинг задач печати (для очереди отображается имя пользователя в сессии)
• Поддержка функций Microsoft Edge Chromium:
  • HTML5 Multimedia Redirection
  • Browser Redirection
  • Geolocation Redirection
  • USB Redirection

Улучшения протокола Blast

Тут довольно много всего нового:

• Функции Blast Virtual Channel security
• Улучшения кодека Blast, включая скорость работы клиентов и улучшения сжатия текста
• Улучшения планировщика frame scheduler, который повышает масштабируемость и уменьшает latency
• Оптимизация создания воркеров Blast
• Поддержка GPU NVIDIA Ampere A10 и A40
• Улучшенная работа кодека NVIDIA GPU при удаленном соединении через Horizon Agent
• Поддержка видео 10-bit HDR 4:2:0 для Windows 10 Agent и Client, а также ВМ с NVIDIA vGPU
• Поддержка видео 10-bit HDR 4:4:4 для Windows 10 Agent и Client, ВМ с NVIDIA vGPU, а также клиентов Intel (Ice Lake+)

Оптимизации Microsoft Teams

Тут появились следующие фичи:

• Обновления WebRTC
• Поддержка Linux для оптимизаций Microsoft Teams
• Поддержка опции Mac Client readback
• Динамическое разрешение видео на базе производительности CPU тонких клиентов
• Улучшенные функции screen sharing для Mac и Linux
• Поддержка Mac для оптимизаций Microsoft Teams как remote app

Групповые политики

Теперь для браузера Microsoft Edge (Chromium) поддерживаются следующие групповые политики:

• Включение HTML5 Multimedia Redirection
• Включение VMware Browser Redirection
• Включение VMware Geolocation Redirection (поддерживается также и для UPD-печати)
• Возможность определить дефолтные настройки для UPD-принтеров
• Поддержка Agent Configuration - настройки для сессий RDS
• Unity Touch and Hosted Apps  - новая настройка "Redirect legal notice messages as a window"
• Поддержка Screen-capture Blocking (см. выше)
• Настройка Sample Rate – Recording Audio Device - устанавливает частоту сэмплирования для хостов RDS и опубликованных приложений.

В следующей статье мы посмотрим на новые возможности клиентов VMware Horizon Clients для различных платформ. А пока вы можете загрузить новую версию VMware Horizon 8 (2106) по этой ссылке. Release Notes доступны тут.

Весной этого года компания VMware выпустила большое обновление серверной платформы виртуализации VMware vSphere 7 Update 2, включающее в себя множество новых возможностей и улучшений. Основные улучшения знает большинство администраторов, так как об этом писали достаточно подробно. Но есть и несколько небольших, но важных изменений, знать про которые было бы очень полезно. Давайте на них посмотрим...

На днях компания VMware объявила о доступности для загрузки VMware Cloud Director 10.3, решения для сервис-провайдеров, предоставляющих виртуальные машины в аренду, которым нужна интегрированная платформа управления облаком. Напомним, что о прошлой версии этого продукта (10.2) мы писали весной этого года вот тут.

Давайте посмотрим на основные новые возможности VCD 10.3:

• Поддержка Kubernetes - тут появились такие новшества, как поддержка кластеров Tanzu Kubernetes для NSX-T Data Center group networking. Теперь для отдельных сервисов можно включить внешний доступ в рамках data center group.
• Сервис-провайдеры и клиенты могут делать апгрейд кластеров Tanzu Kubernetes с использованием графического интерфейса, а также использовать vRealize Operations Tenant App для учета потребления ресурсов Kubernetes.
• Клиенты могут использовать единую точку доступа API для всех операций жизненного цикла решений Tanzu Kubernetes Grid Service, Tanzu Kubernetes Grid и непосредственно Kubernetes.
• Улучшения интерфейса по работе с режимом FIPS-compliant.
• Поддержка в API приложений vApp при их перемещении между vCenter.
• Улучшения интерфейса при работе с каталогом.
• Поддержка VMware Cloud Director Service Library для vRealize Orchestrator 8.x (для этого есть vRealize Orchestrator plug-in, который позволяет имплементировать рабочие процессы vRO для клиентов VCD).
• Улучшенные функции поиска Quick Search и Global Search в интерфейсе.
• Улучшения производительности расширения Auto Scaling.
• Поддержка vApp network services в окружении NSX-T - вы можете использовать NAT, фаервол и статическую маршрутизацию для сетей виртуальных приложений vApp.
• Поддержка Distributed Firewall Dynamic Group Membership в окружении NSX-T - можно создавать группы безопасности ВМ с динамическим членством, которое основано на базе различных параметров ВМ (например, шаблон имени или тэги). Для таких групп можно создавать правила фаервола, что позволяет микросегментировать сетевой трафик и эффективно защищать группы ВМ.
• Сервис-провайдеры могут создавать внешние сети на базе VLAN и оверлеев сегментов NSX-T Data Center.
• Сервис-провайдеры могут импортировать сети на базе DVPG. Администратор может импортировать распределенную портгруппу из Distributed Switch и расшарить эти сети между группами датацентра.
• Поддержка VLAN и пулов port-group network pools для VDC на базе NSX-T Data Center.
• Поддержка создания VDC без ассоциации с NSX Data Center for vSphere, NSX-T Data Center Update port groups или внешними сетями.
• Поддержка решений Avi версий 20.1.3 и 20.1.4.
• Поддержка конфигурации DHCPv6 и SLAAC, а также назначения primary IP address шлюзу NSX-T edge gateway в интерфейсе.
• Поддержка создания и управления статическими пулами IPv6.
• Просмотр списка VDC group networks в интерфейсе.
• Улучшения назначений для Edge Cluster.
• Поддержка управления DHCP для изолированных сетей в VDC на базе NSX-T Data Center.
• Сервис-провайдеры могут менять основные настройки Avi SEG.
• Новый раздел Tier-0 Gateway Networking на портале Service Provider Portal.
• Аллоцированные IP-адреса DHCP видны на экране VM details.
• Можно изменять и удалять DHCP-пулы из сетей на базе NSX-T Data Center.
• Действие Reject для правил фаервола NSX-T Data Center edge gateway (также можно нотифицировать клиента о заблокированном трафике).
• Можно изменять приоритет правил NAT.
• Поддержка Reflexive NAT.
• Поддержка импортированных сетей VMware Cloud on AWS.
• Для внутренних подсетей поддерживаются службы Advertise services с механизмом route advertisement.
• Поддержка сетей /32 в качестве внешних для NSX-T Data Center.
• Поддержка Guest VLAN Tagging для сегментов сетей NSX-T Data Center.
• Доступность Alpha API - теперь администраторы могут использовать включенный по умолчанию API, который позволяет управлять кластерами Kubernetes Container Cluster, а также предоставляет возможности Legacy API Login.

Более подробную информацию о новом релизе VMware Cloud Director 10.3 можно получить в Release Notes. Скачать его можно по этой ссылке.

В начале июня мы писали об обновлении решения для аналитики лог-файлов и мониторинга инфраструктуры VMware vRealize Log Insight Cloud, в котором появилась интересная возможность Live Tail для горячего мониторинга логов, в которых вы ищете источники проблем.

На днях VMware заявила о выпуске обновлений продуктов линейки VMware vRealize 8.5, среди которых есть и обновление vRealize Log Insight Cloud 8.5. Давайте посмотрим, что там появилось нового:

• Поддержка нового региона - Сингапур. Теперь Log Insight Cloud доступен в регионе AWS Asia Pacific (Singapore). Помимо этого, решение уже работает в регионах US West, Asia Pacific (Sydney), Europe (Frankfurt) и Canada (central).
• Улучшенные фильтры Log Forwarding. Теперь они поддерживают новые опции, например, проверки на существование того или иного поля. Можно сделать комплексный фильтр - если поле существует, то уже смотреть его значение по условиям. Далее можно уже отправлять события во внешнее назначение.
• Пользователи теперь могут получать доступ к файлам VMware Cloud SDDC Grouping activity logs, которые появляются при создании/обновлении/удалении SDDC Group, добавлении/удалении нового члена группы SDDC, добавлении/удалении Direct Connect Gateway из группы, добавлении/удалении External AWS Account и обновлении external attachments.

Запросить пробную версию VMware vRealize Log Insight 8.5 можно по этой ссылке.

Также компания VMware обновила свое решение для комплексного управления и мониторинга виртуальной инфраструктуры в различных аспектах vRealize Operations Cloud и vRealize Operations 8.5. О прошлой версии vRealize Operations 8.4 мы писали весной этого года вот тут.

Это минорный релиз, который, в основном, добавляет исправления ошибок и обновления безопасности. Release notes по продуктам находятся тут.

Давайте посмотрим, что нового появилось в vROPs 8.5:

• Поддержка нового региона - Сингапур. Теперь Log Insight Cloud доступен в регионе AWS Asia Pacific (Singapore). Помимо этого, решение уже работает в регионах US West, Asia Pacific (Sydney), Europe (Frankfurt) и Canada (central).
• Новый vRealize Operations Cloud Management Pack for Managed Service Providers (MSP). Он позволяет объединить разные инсталляции vRealize Operations Cloud у сервис-провайдеров в единую панель управления. В рамках каждой инсталляции на разных сайтах под управлением сервис-провайдера может находиться множество клиентов. Вот основные возможности, которые предоставляет данный MP:
  • Сводная статистика производительности, емкостей и конфигураций для всех окружений клиентов на разных площадках.
  • Возможность создать data warehouse с набором выбранных метрик, которые потом можно использовать для построения исторических отчетов.
  • Возможность создания сводного представления о текущем статусе работоспособности разных компонентов виртуальных датацентров, в том числе основных решений VMware - vCenter Server, NSX и vSAN. Также доступен мониторинг жизнедеятельности vRealize Operations, vRealize Log Insight, vRealize Automation, vRealize Business и VMware Site Recovery Manager.

Загрузить пробную версию VMware vRealize Operations 8.5 можно по этой ссылке.

После выхода VMware vSphere 7 Update 2 появилось много интересных статей о разного рода улучшениях, на фоне которых как-то потерялись нововведения, касающиеся работы с большими нагрузками машинного обучения на базе карт NVIDIA, которые были сделаны в обновлении платформы.

А сделано тут было 3 важных вещи:

• Пакет NVIDIA AI Enterprise Suite был сертифицирован для vSphere
• Появилась поддержка последних поколений GPU от NVIDIA на базе архитектуры Ampere  
• Добавились оптимизации в vSphere в плане коммуникации device-to-device на шине PCI, что дает преимущества в производительности для технологии NVIDIA GPUDirect RDMA

Давайте посмотрим на все это несколько подробнее:

1. NVIDIA AI Enterprise Suite сертифицирован для vSphere

Основная новость об этом находится в блоге NVIDIA. Сотрудничество двух компаний привело к тому, что комплект программного обеспечения для AI-аналитики и Data Science теперь сертифицирован для vSphere и оптимизирован для работы на этой платформе.

Оптимизации включают в себя не только средства разработки, но и развертывания и масштабирования, которые теперь удобно делать на виртуальной платформе. Все это привело к тому, что накладные расходы на виртуализацию у задач машинного обучения для карточек NVIDIA практически отсутствуют:

2. Поддержка последнего поколения NVIDIA GPU

Последнее поколение графических карт для ML-задач, Ampere Series A100 GPU от NVIDIA, имеет поддержку Multi-Instance GPU (MIG) и работает на платформе vSphere 7 Update 2.

Графический процессор NVIDIA A100 GPU, предназначенный для задач машинного обучения и самый мощный от NVIDIA на сегодняшний день в этой нише, теперь полностью поддерживается вместе с технологией MIG. Более детально об этом можно почитать вот тут. Также для этих карт поддерживается vMotion и DRS виртуальных машин.

Классический time-sliced vGPU подход подразумевает выполнение задач на всех ядрах GPU (они же streaming multiprocessors, SM), где происходит разделение задач по времени исполнения на базе алгоритмов fair-share, equal share или best effort (подробнее тут). Это не дает полной аппаратной изоляции и работает в рамках выделенной framebuffer memory конкретной виртуальной машины в соответствии с политикой.

При выборе профиля vGPU на хосте с карточкой A100 можно выбрать объем framebuffer memory (то есть памяти GPU) для виртуальной машины (это число в гигабайтах перед буквой c, в данном случае 5 ГБ):

Для режима MIG виртуальной машине выделяются определенные SM-процессоры, заданный объем framebuffer memory на самом GPU и выделяются отдельные пути коммуникации между ними (cross-bars, кэши и т.п.).

В таком режиме виртуальные машины оказываются полностью изолированы на уровне аппаратного обеспечения. Выбор профилей для MIG-режима выглядит так:

Первая цифра сразу после a100 - это число слайсов (slices), которые выделяются данной ВМ. Один слайс содержит 14 процессоров SM, которые будут использоваться только под эту нагрузку. Число доступных слайсов зависит от модели графической карты и числа ядер GPU на ней. По-сути, MIG - это настоящий параллелизм, а обычный режим работы - это все же последовательное выполнение задач из общей очереди.

Например, доступные 8 memory (framebuffers) слотов и 7 compute (slices) слотов с помощью профилей можно разбить в какой угодно комбинации по виртуальным машинам на хосте (необязательно разбивать на равные части):

3. Улучшения GPUDirect RDMA

Есть классы ML-задач, которые выходят за рамки одной графической карты, какой бы мощной она ни была - например, задачи распределенной тренировки (distributed training). В этом случае критически важной становится коммуникация между адаптерами на нескольких хостах по высокопроизводительному каналу RDMA.

Механизм прямой коммуникации через шину PCIe реализуется через Address Translation Service (ATS), который является частью стандарта PCIe и позволяет графической карточке напрямую отдавать данные в сеть, минуя CPU и память хоста, которые далее идут по высокоскоростному каналу GPUDirect RDMA. На стороне приемника все происходит полностью аналогичным образом. Это гораздо более производительно, чем стандартная схема сетевого обмена, об этом можно почитать вот тут.

Режим ATS включен по умолчанию. Для его работы карточки GPU и сетевой адаптер должны быть назначены одной ВМ. GPU должен быть в режиме Passthrough или vGPU (эта поддержка появилась только в vSphere 7 U2). Для сетевой карты должен быть настроен проброс функций SR-IOV к данной ВМ.

Более подробно обо всем этом вы можете прочитать на ресурсах VMware и NVIDIA.

Многие Enterprise-администраторы настраивают автоматический регулярный бэкап решения для виртуализации и агрегации сетей VMware NSX-T из консоли, что описано, например, вот тут.

Между тем, как правильно заметил автор virten.net, при неудачном завершении задачи резервного копирования администратор не получает нотификации даже в дэшборде в разделе алармов.

В случае падения задачи бэкапа информация об этом доступна только в разделе Backup & Restore настроек:

Эту информацию можно получить и через API:

> GET /api/v1/cluster/backups/history HTTP/1.1
{
  "cluster_backup_statuses": [
    {
      "backup_id": "5cf21742-091a-b9b9-1f24-ad75ede2d23b-1615489436",
      "start_time": 1615489436085,
      "end_time": 1615489440865,
      "success": false,
      "error_code": "BACKUP_AUTHENTICATION_FAILURE",
      "error_message": "either backup server login failed or unauthorized access to backup directory"
    }
  ],
  "node_backup_statuses": [
    {
      "backup_id": "5cf21742-091a-b9b9-1f24-ad75ede2d23b-1615403036",
      "start_time": 1615403036017,
      "end_time": 1615403354709,
      "success": true
    }
  ],
  "inventory_backup_statuses": [
    {
      "backup_id": "inventory-1615490636",
      "start_time": 1615490636254,
      "end_time": 1615490641758,
      "success": true
    }
  ]
}

В данном примере неудачно завершился процесс резервного копирования кластера, поэтому нужно смотреть не только на статусы узлов (кстати, времена указаны в миллисекундах).

Коллега с virten.net написал сценарий на Python для Nagios, который позволит вам проверить статус последнего бэкапа кластера NSX-T, а также посмотреть возраст последней имеющейся резервной копии:

usage: check_nsxt_backup.py [-h] -n NSX_HOST [-t TCP_PORT] -u USER -p PASSWORD
                            [-i] [-a MAX_AGE]

# python check_nsxt_backup.py -n nsx.virten.lab -u audit -p password
NSX-T cluster backup failed
NSX-T node backup is to old (1461 minutes)